개요

기본 사항

https://catalog.us-east-1.prod.workshops.aws/workshops/26d69ada-3c22-452f-9f7e-84233d4eab4c/ko-KR
24년 2분기의 워크숍에 진행됐던 내용을 바탕으로 실습을 진행한다.

주제

대화형 쿼리를 받을 수 있는 챗봇, 프롬프트 명령에 따라 요약을 수행하는 AI 앱을 구축한다.
노 코드로 구축, 배포 하는 것을 목적으로 한다.
AI를 활용하기 위해 Amazon Bedlock을 사용한다.
또한 모니터링 가능한 대시보드를 제공한다.

구조적 이점

운영 우수성 원칙

• AWS CloudFormation 템플릿을 코드형 인프라로 사용하여 구축
• Amazon Lambda 함수로 사용자 지정 지표를 Amazon CloudWatch 및 사용자 지정 대시보드에 푸시하여 솔루션 상태 모니터링
• 구성 요소는 모듈화되어 배포할 구성 요소를 선택할 수 있는 유연성을 제공

보안 원칙

• Amazon Cognito를 통해 인증 및 승인
• 모든 통신은 AWS Identity and Access Management 역할 사용
• 모든 솔루션 역할은 필요한 최소 권한만 사용
• Amazon S3, Amazon DynamoDB 및 Amazon Kendra를 포함한 모든 데이터 스토리지에는 저장 암호화 기능
• 배포 대시보드와 채팅 웹사이트는 모두 AWS Web Application Firewall로 보호

안정성 원칙

• 서버리스 패러다임 기반
• 온디맨드, 수평적 확장성 및 기본 인프라 오류로부터의 자동 복구
• 기본 엔드포인트를 압도하지 않도록 요청에 대한 버퍼링 및 제한

성능 효율성 원칙

• Amazon DynamoDB
• Amazon S3 사용하고 Amazon CloudFront 통해 웹호스팅 확장 가능한 스토리지 제공

비용 최적화 원칙

• 서버리스 아키텍처 구축
• 사용한 만큼 비용

지속 가능성 원칙

• 모듈식, 구성요소화된 아키텍처
• 프로비저닝할 리소스를 사용자 정의 가능한 유연성
• 리소스 활용도를 최적화하는 서버리스 컴퓨팅 및 스토리지
• 클라우드 기반 솔루션이라 공유 리소스, 네트워킹, 전력 냉각 및 물리적 시설의 이점

아키텍쳐

배포 아키텍처

이 모든 설계와 구축은 데브옵스 엔지니어가 관리자를 위해 제공한다.

프로세스

• 관리자는 Amazon CloudFront로 Amazon S3의 호스팅된 웹에 접근
  • AWS Web Application Firewall를 통해 방화벽을 세우고 보안성 확보
• Amazon Gateway에서 RESTapi 제공
• 각 접근에 대해서 Amazon Cognito를 통해 사용자 인증 및 인가
• Amazon Lambda로 비즈니스 로직 담당.
  • 원리
    • AWS CloudFormation을 통해 필요 리소스 생성
    • Amazon DynamoDB로 구성 세부 정보 저장
    • LLM을 사용할 때 키 저장을 위해 Amazon Secrets Manager 사용
    • LLM 구성 정보는 Amazone System Manager에 저장되고, LLM 구성 시 활용
  • 흐름
    • 관리자의 요청에 따라 챗봇 관련 리소스 생성
• Amazon CloudWatch를 통해 운영 모니터링

챗봇 아키텍처

관리자가 만들어낸 서비스를 이용하는 사용자들에게 제공되는 아키텍처는 이러한 모양을 띄고 있다.

프로세스

• 사용자는 UI를 통해 로그인을 진행
  • Amazon CloudFront로 구축된 웹소켓에 접근하고, Amazon Gateway로 로직 실행
  • Amazon Cognito로 인증 받은 사용자만 위의 서비스 활용
• Lambda Orchestrator
  • 사용자의 모든 요청을 이행하는 Amazon Lambda 계층의 모음
  • Amazone System Manager의 parameter store, Amazon DynamoDB에서 세션 정보 가져옴
  • Amazon Kendra를 통해 RAG 활용 및 쿼리문 작성
  • 작성된 쿼리문으로 Amazon Bedlock으로 호스팅된 LLM 사용
• LLM의 요청이 돌아오면 Amazon Gateway의 웹소켓을 통해서 돌아감

실습

실습 페이지에서 제공하는 템플릿을 그대로 활용한다.
https://github.com/Zerotay/practice-aws/tree/main/workshop/gen-ai
직접 분석을 해볼까 생각했는데, 코드의 양이 말이 안 되게 길다.
AWS CloudFormation#IaC 생성기 보니까 왜 이렇게 긴지 알 것 같다.
Amazon Kendra, Amazon Bedlock은 24.7.4 기준 서울 리전에 존재하지 않으므로 다른 리전에서 진행한다.

세팅

application composer에서 보면 이렇게 생겼다.

어드민 이메일 계정은 지정해야 나중에 Amazon Cognito에 인증이 되는 유저의 정보를 받을 수 있게 된다.

템플릿의 정보를 간단하게 읽고, 이러한 정보에 대한 경고를 해준다.

이벤트 로그에 템플릿 내부의 지정사항들이 보이는 게 확인된다.
상태 사유에 대한 내역도 나오는데, 내가 처음으로 만든 녀석은 User Initiated로 표시된다.
나머지는 내가 직접 만드는 건 아니라 표시가 다르다.

조금 기다리다가 스택을 전체 확인해보면 중첩으로 몇 개의 스택이 추가적으로 구성된 것을 확인할 수 있다.
그러나 막상 들어가보면 아직 생성 중이라고 표시되는 것들도 많다.
필요 시에 생성되는 것들도 표시는 되는 것이라고 생각하면 될 것 같다.

출력 부분을 보면 이렇게 찍혀 있는 것이 확인된다.
이건 코드 상에서 Ouputs라는 부분에 제시된 정보이다.
값을 이런 식으로, Fn이라는 특수 함수를 이용해서 값을 불러오는 것을 확인할 수 있다.
사람이 직접 짠 건지, 아니면 알아서 짜주도록 엔지니어가 설계한 것인지는 모르겠다.
코드를 까보니 vpc 관련 설정을 했다면 관련 정보도 출력됐을 것으로 생각된다.
아무튼 클라우드프론트 url이 나왔고, 메일로 들어갈 수 있는 계정에 대한 정보가 전달됐다.

로그인을 하고 나면 이런 화면이 튀어나온다.
배포를 할 수 있는 입장인 것이다.

베드록의 모델을 사용하고 그냥 설정을 진행해보면, 클라우드 포메이션이 하나 생성되는 것이 확인된다.

오랜 시간 접속 안 했다가 다시 들어가니 이렇게 사용자가 맞는지 재인증하는 절차가 있다.
이것도 참고하면 좋겠다.

Amazon CloudWatch를 들어가서 모니터링도 가능하다.

재밌게도, 에러가 뜨고 있다.
Amazon X-Ray로 확인해봐야 하나?

문제는 여기에 있는 것 같다.
단순하게, 모델 접근 권한이 존재하지 않는 것이다.
나는 이전에 오레곤 지역에서만 권한을 받았으니까, 어쩔 수 없는 것 같기도 하다.
그런데 성능이 좋다는 3.5를 쓸 수 없다는 점이 조금 아쉽다.
나중에 서울 리전으로 옮겨서 진행할 수 있을까 궁금하다.

상향식 분석

스캐닝

이 이상의 실습은 사실 큰 의미는 없다고 생각한다.
클라우드 포메이션으로 뚝딱으로 끝이니 이걸 내가 어떻게 다시 설계할 수 있겠냐.
그래서 반대로 상향식으로 모든 리소스들을 찾아들어가 분석해보자.

라고 생각하고 찾아봤는데, 대충 리소스가 300개는 넘는 것 같다..?
물론 대다수는 사용자가 직접적으로 만들 수 있는 리소스가 아닌 듯하다.
대충 봐도 선택을 할 수 없는 리소스들도 보인다.

이건 조금 이후에 알게 된 것인데, 태그를 지정하면 Amazon Resource Groups에서 확인을 해볼 수 있다.

이렇게 말이다.

아키텍쳐를 통한 분석

아니면 아키텍처가 만들어져 있으니까 이걸 순서대로 훑어보는 것도 방법일 것이다.
배포 아키텍처를 먼저 살펴보자.

배포 아키텍처

프론트엔드

사용자는 처음에 접근하는 리소스가 바로 Amazon CloudFront이다.

어쩌다가 하나의 배포가 더 생긴 것인지는 잘 모르겠다.
다만 이전에는 이해하기 좋게, 배포용 사이트와 챗봇용 사이트만이 존재했다.

AWS Web Application Firewall 설정은 안 돼 있는 것으로 나온다.
이것은 나중에 직접 추가해보는 시도를 해볼 수 있겠다.

원본이라는 것이 존재한다.

S3가 지정이 돼있는데, 확인해보니 확실히 이러한 놈이 있었다.
아마 여기에 정적 페이지가 담겨있을 것이라고 생각한다.

직접 index.html 파일을 찾아서 봤는데, 이렇게 나온다.
이건 딱 답이 나온다.
그냥 빌드한 다음에 Amazon S3에 올리고, Amazon CloudFront에 올리면 기본적인 프론트를 구성할 수 있는 것이다.
별 상관이 없다고만 한다면 S3 자체에서 호스팅하는 것도 가능할 텐데, 그럴 경우 TLS 인증이 어려울 것으로 생각된다.

아직 궁금한 점은 어떻게 TLS 인증이 일어나냐는 것이다.
그건 여기에서 답을 찾을 수 있다.
바로 리디렉션을 시키는 동작 정책이 존재한다.
이건 가격이 드는 녀석인가?

안 속에는 또 다시 원본이 존재한다.
https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-s3-origin.html
S3에 대한 https 연결, 찾은 것 같다.
s3에서 부터 https 연결을 지원하도록 해야 한다.
사실 진행 자체는 그냥 간단하게 설정하는 칸에서 설정만 진행하면 되는 모양이다.

오류 페이지를 기본 페이지로 돌아가게 만드는 것.

이건 AWS Web Application Firewall에 대한 정보이다.
cloudfront에서는 전혀 추적할 수 없었는데, 여기에는 정보가 나온다.

왜냐하면 Amazon Gateway에 걸린 방화벽이기 때문이다..
그럼 이제 Amazon Cognito와 Amazon Gateway를 찾아볼 단계이다.

게이트웨이 1, 코그니토

AWS Web Application Firewall와 연결된 게이트웨이가 쉽게 확인된다.

다양한 API가 들어있다.
CORS 문제를 막기 위한 options를 제외하면 각각이 Amazon Lambda와 연결되어 있을 것으로 생각된다.
그럼 그 람다가 어떻게 생겼냐,

조낸 길고 복잡하다;;
아키텍쳐가 복잡해진다면 백엔드가 할 일의 영역이 엄청나게 커질 것이라는 것은 당연하긴 하다.
이거 일일히 내가 이해할 수 있을지가 걱정이다.
일단 결국 api 명세서를 작성해야 이런 것을 구성할 수 있다는 것을 생각하자.
그래야 프론트에도 붙일 수 있다.
람다는.. 사용 사례를 조금 더 찾아봐야 따라할 수 있을 것으로 생각된다.
람다 그룹을 생성해서 코드를 공유해서 사용하는 케이스가 있다고 하니 그런 것 관련해서도 일단 염두해두자.

이것보다는 Amazon Cognito를 먼저 파보자.
여기는 말 그대로 oauth이다.
가입은 어떻게 제한할 거고, 누가 허용됐고, 이런 정보들
메시징 기능도 있따.
근데 이걸 어떻게 만들었을까?
프론트 단에서 바로 이쪽과 연결되도록 코드를 짰나?
솔직히 이건 암만 봐도 모르겠다.
내 생각에는 여기에 있는 키를 활용해서 그냥 각 리소스들이 참조를 하는 것 같다.
이건 튜토리얼을 보던가 해야지..

백엔드 로직 1

람다가 클라우드포메이션을 가동시키고, 그렇게 진정으로 우리의 실습 목적인 베드록이 만들어진다.
그래서 어떤 게이트웨이의 엔드포인트가 생성을 하는지 보고 싶었는데, 이거 찾기가 쉽지가 않다.
웹페이지를 뜯어서 찾아보려고 했으나, 결국 전부 난독화가 진행돼서 확인할 수가 없다.
그냥 이름만 보고 대충 때려맞춰보는 수밖에.

뭐.. 대충 deployment 관련 POST 요청이면 만드는 거겠지.
하나의 람다에 여러 개의 게이트웨이를 붙일 수 있다는 것도 처음 알았다.

람다 함수를 어떻게든 찾아서 파봤는데, 타쓰로 작성돼있다 보니까 직관적이지는 않았다.
그리고 커맨드 패턴, 어댑터 패턴을 적극적으로 활용하다보니까 처음에 눈에 익지도 않았기도 했는데, 결국 알아낸 지점 중 하나는 있었다.
위에 나온 아키텍쳐가 정말 설명을 잘해주고 있었다는 것이다.

나머지 분석

직접적으로 람다를 다 파헤쳐가면서 모든 것을 파악하기는 매우 어려울 것으로 보인다.
개수가 너무 많다..
그래서 여기에서부터는 아키텍쳐를 기준으로 연결 관계를 파악해보고자 한다.
그렇게 볼 것은 Amazon CloudWatch, Amazon Secrets Manager이다.

이 중에서 Amazon Secrets Manager는 실제 데이터가 없어서 확인할 수가 없다.

정리

먼저 배포한 리소스를 삭제한다.

ui에서는 금방인 것처럼 보였지만, 실은 조금씩 삭제가 진행되는 모습이다.
그 다음에는 처음 AWS CloudFormation에서 만들었던 스택을 삭제하면 기본적인 삭제가 완료된다.
만약 RAG을 위한 설정을 추가했다면 그것에 대한 삭제는 수동으로 진행하도록 한다.